Add support for HTTP/2 - #13039

@@            Coverage Diff             @@
##           master   #13039      +/-   ##
==========================================
- Coverage   98.98%   98.94%   -0.04%     
==========================================
  Files         132      139       +7     
  Lines       49073    50403    +1330     
  Branches     2553     2647      +94     
==========================================
+ Hits        48576    49873    +1297     
- Misses        373      392      +19     
- Partials      124      138      +14     

Flags with carried forward coverage won't be shown. Click here to find out more.

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

• aiohttp/client.py:253 HTTP/2 path returns Http2Response, not ClientResponse — breaks the public API contract
• aiohttp/connector.py:329 Global Semaphore(1) serializes ALL connection establishment, including HTTP/1.1
• aiohttp/connector.py:868 os.getenv truthiness check enables h2 for any value, including "0" and "false"
• aiohttp/client.py:254 Manual _conns insertion + conn._protocol=None leaks connector accounting slots
• aiohttp/http2/connection.py:44 Module sets logger level to DEBUG at import; frame send/recv logs eagerly on the hot path
• aiohttp/http2/connection.py:209 Incoming frame handling: no frame-size cap, padding underflow, and a shared flow-control Event across streams

async with connector.sem: wraps connector.connect() unconditionally, and self.sem = asyncio.Semaphore(1) is created for every BaseConnector regardless of whether AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS is set (connector.py:410).

Two distinct harms, both on the default path every aiohttp user hits:

• Serialized handshakes. N concurrent requests that each need a fresh connection now complete their TCP+TLS handshakes strictly one at a time. This is the measurable regression on the non-h2 test_one_hundred_simple_get_requests* benchmarks.
• Head-of-line blocking across hosts. connect() does not return quickly when the pool is saturated — it awaits _wait_for_available_connection() (connector.py:713), which blocks until timeout.connect. A single request stalled on host A's limit_per_host therefore holds the process-wide semaphore and blocks every request to unrelated hosts B, C, D behind it. That is a new stall of up to the full connect timeout on traffic that has nothing to do with HTTP/2.

How to fix: as you proposed in the thread, at minimum skip the semaphore entirely when the experimental flag is off. Better: move the coordination inside the connector, key it per ConnectionKey, and only hold it across the first connect to a host whose ALPN result is still unknown — never across _wait_for_available_connection().

(Noting your comment that the general host-tracking optimisation is follow-up work — that part is fine to defer. The unconditional serialization of the HTTP/1.1 path is what blocks here, and you already agreed it should be gated.)

        async with connector.sem:
            # at most just one
            conn = await connector.connect(
                req, traces=req._traces, timeout=req._timeout
            )

HttpDispatcherProtocol now replaces ResponseHandler as the factory for all connections (connector.py:379), and every attribute access on it goes through a Python-level __getattribute__ that does a str.startswith plus a set-membership test before delegating.

Why it matters:

• data_received is dispatched by asyncio through this wrapper on every TCP read, and conn.protocol.<attr> is touched many times per request (transport, should_close, writing_paused, set_response_params, closed, …). Adding an interpreted __getattribute__ to the single hottest object in the client is a permanent tax on the HTTP/1.1 path — the path this feature is supposed to leave untouched.
• __setattr__ forwards to self._handler, which is None until connection_made. Any attribute access before then raises AttributeError: 'NoneType' object has no attribute .... Today this is masked rather than safe: CPython's sslproto.SSLProtocol._set_app_protocol does hasattr(app_protocol, 'get_buffer'), and hasattr swallows the AttributeError, so it happens to return False — by accident, not by design.
• Subclassing plain asyncio.Protocol also makes isinstance(proto, BufferedProtocol) permanently False, so the wrapper structurally blocks aiohttp from ever adopting the buffered-protocol read path on the client. (ResponseHandler is not a BufferedProtocol today, so this is latent, not a live regression.)
• __slots__ on a subclass of asyncio.Protocol (which has no __slots__) does not remove __dict__, so it buys nothing here.

How to fix: dispatch explicitly rather than by proxy. Implement the six asyncio.Protocol callbacks as thin forwarders and have the connector unwrap to the concrete handler once ALPN is known (e.g. return the real handler from _wrap_create_connection / _start_tls_connection instead of keeping the wrapper alive for the lifetime of the connection). That removes the per-access cost from the HTTP/1.1 path entirely and makes the type honest, which also removes the need for the two # type: ignore[return-value] HACKs.

    def __getattribute__(self, name: str) -> Any:
        if not name.startswith("__") and name not in {
            "connection_made",
            "__getattribute__",
            "_handler",
            "_transport",
            "_loop",
        }:
            return getattr(self._handler, name)
        return super().__getattribute__(name)

(":authority", url.host) builds the authority pseudo-header from yarl.URL.host, which is the decoded host and never carries the port.

Why it matters:

• Requests to a non-default port (https://example.com:8443/) send :authority: example.com. RFC 9113 §8.3.1 requires the authority to include the port when it is not the scheme default. Virtual-hosted and port-multiplexed servers will route to the wrong vhost or reject the request. The bug is unrecoverable at the server because send_request also strips the client's host header (line ~500), so there is no fallback.
• For IDN hosts, url.host returns the Unicode form (пример.рф) where raw_host returns the ASCII/punycode form. Emitting non-ASCII in a pseudo-header is a protocol violation.

How to fix: use url.raw_authority (or raw_host plus url.explicit_port), matching how the HTTP/1.1 path builds the Host header.

Note this is untested: url_mock() in tests/http2/test_http2.py has no port and no raw_host, so no test exercises either case.

        req_headers = [
            (":method", method),
            (":path", path_and_query),
            (":scheme", url.scheme),
            (":authority", url.host),
        ]

The guard accepts any identifier in 0..9, but Setting only defines 1,2,3,4,5,6,8,9. A SETTINGS frame carrying identifier 0x0 or 0x7 therefore reaches Setting(identifier) and raises ValueError: 0 is not a valid Setting, which propagates out of data_received — i.e. out of an asyncio transport callback, where it becomes an unhandled exception and leaves the connection wedged with all pending stream futures never resolved.

Why it matters: RFC 9113 §6.5.2 says an endpoint receiving an unknown or unsupported setting identifier MUST ignore that setting. Identifier 0x7 is unassigned and is exactly the kind of value a GREASE-style or future-extension server emits, so a spec-compliant peer can break the connection.

How to fix: replace the numeric range check with membership, e.g.

try:
    setting = Setting(identifier)
except ValueError:
    logger.debug("Ignoring unknown setting identifier %d", identifier)
    continue

(identifier < 0 is also dead — !H is unsigned.)

            identifier, value = struct.unpack("!H I", payload[i : i + 6])
            if identifier < 0 or identifier > 9:
                logger.warning("Unknown setting identifier %d", identifier)
                continue
            setting = Setting(identifier)

Two server-controlled inputs can raise out of data_received:

• extra.decode() is evaluated eagerly as a logger.info argument. GOAWAY's Additional Debug Data field is opaque octets (RFC 9113 §6.8) — any non-UTF-8 byte raises UnicodeDecodeError. Because the connection is going away anyway, the failure silently strands every stream future instead of resolving them with ConnectionError.
• struct.unpack("!I I", payload[:8]) raises struct.error if a peer sends a truncated GOAWAY.

The same fixed-width-unpack assumption exists in _handle_rst_stream_frame (struct.unpack("!I", payload) needs exactly 4 bytes) and _handle_window_update_frame.

Why it matters: these are the paths that run when a connection is already failing, so a crash here converts "connection closed cleanly" into "all in-flight requests hang until timeout".

How to fix: length-check the payload before unpacking, and log the debug data with %r on the raw bytes (or extra.decode(errors="replace")) using lazy %s args. Also mask the reserved bit and reject a zero increment in WINDOW_UPDATE per §6.9.

        self._goaway_received = True
        last_stream_id, error_code = struct.unpack("!I I", payload[:8])
        extra = payload[8:]
        self._last_stream_id = last_stream_id
        self._error_code = error_code
        logger.info(
            "GOAWAY received: last_stream=%d, error=%d, extra=%s",
            last_stream_id,
            error_code,
            extra.decode(),
        )

data = payload[pos : len(payload) - pad_length] with no check that pad_length < len(payload).

If a peer sends pad_length >= len(payload) the end index goes negative, Python slices from the front, and the handler silently delivers a truncated (or empty) body to the caller. RFC 9113 §6.1 states this MUST be treated as a connection error of type PROTOCOL_ERROR.

Why it matters: a buggy or hostile server can silently corrupt response bodies with no error surfaced to the application — the worst failure mode for an HTTP client, since callers have no way to detect it. The # padding might be too long comment shows the case was noticed but not handled.

How to fix:

if flags & FlagData.PADDED:
    pad_length = payload[0]
    pos = 1
    if pad_length >= len(payload):
        self._protocol_error()
        return

The same applies to the PRIORITY-flag branch in _handle_headers_frame, which does an unchecked payload = payload[5:].

        # padding might be too long
        data = payload[pos : len(payload) - pad_length]

data_received reads the 24-bit length field and buffers until the whole frame arrives, without validating it against the MAX_FRAME_SIZE this client advertises (16384 by default, settings.py).

Why it matters: a peer can declare a 16 MB frame and dribble it, and self._frame_buffer grows to hold all of it with no ceiling and no timeout. With multiplexing there is one such buffer per connection but nothing caps how many partial frames accumulate, so this is a cheap memory-exhaustion vector against a client that is only opted into an experimental flag. aiohttp's HTTP/1.1 parser enforces max_line_size/max_field_size for exactly this reason — the h2 parser should have equivalent limits.

RFC 9113 §4.2: a frame larger than the receiver's SETTINGS_MAX_FRAME_SIZE MUST be treated as a FRAME_SIZE_ERROR.

How to fix: reject with _protocol_error() when length > self.local_settings[Setting.MAX_FRAME_SIZE], before buffering. Worth also capping total buffered response bytes per stream so Stream.response_data cannot grow without limit (ClientResponse has read_bufsize/max_line_size equivalents; Http2Response has none).

            if len(self._frame_buffer) < FRAME_HEADER_LENGTH + length:
                break  # incomplete frame; wait for more data

os.getenv(...) returns a string, and every non-empty string is truthy. AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS=0, =false, and =off all enable h2 negotiation.

Why it matters: an operator who explicitly disables the experimental protocol the obvious way silently turns it on and starts exercising an unfinished code path in production. An opt-in gate that cannot be turned off is worse than no gate.

How to fix: compare explicitly — if os.getenv("AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS") == "1": — or accept a small truthy set. The False default is also the wrong type for getenv; drop it.

(Independently, @Dreamsorcerer asked for this to be a ClientSession parameter rather than an env var — see the reply on that thread.)

    protocols = ["http/1.1"]
    if os.getenv("AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS", False):
        protocols += ["h2"]

_make_ssl_context() is called exactly twice, at module import:

_SSL_CONTEXT_VERIFIED = _make_ssl_context(True)
_SSL_CONTEXT_UNVERIFIED = _make_ssl_context(False)

So the ALPN list — and therefore whether h2 is offered at all — is frozen when aiohttp.connector is first imported.

Why it matters: the most natural way a user enables an opt-in flag from Python is

import aiohttp
os.environ["AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS"] = "1"

which silently does nothing — no error, no warning, just HTTP/1.1 forever. The flag only works if set in the process environment before the first import aiohttp. Nothing in the PR description says this.

It also makes the feature awkward to test: any test that sets the env var via monkeypatch.setenv will not affect the already-built default contexts.

How to fix: decide the ALPN list per-connector rather than per-module (or, per @Dreamsorcerer, drive it from a ClientSession/TCPConnector parameter, which sidesteps the problem entirely). If the env var stays, document the import-time constraint explicitly.

        sslcontext.verify_mode = ssl.CERT_NONE
        sslcontext.options |= ssl.OP_NO_COMPRESSION
        sslcontext.set_default_verify_paths()

    protocols = ["http/1.1"]
    if os.getenv("AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS", False):
        protocols += ["h2"]
    sslcontext.set_alpn_protocols(tuple(protocols))

import time and from collections import deque were added for the earlier connector._conns[key] = deque([(proto, time.monotonic())]) approach. That code has since been replaced by the connector._release(...) calls, and neither name is referenced anywhere in the current client.py diff.

Why it matters: flake8 runs on all files via pre-commit with no exclude for aiohttp/, so both trigger F401 imported but unused and the lint job fails before any reviewer sees the substance of the PR.

How to fix: drop both imports and run pre-commit run --all-files (per AGENTS.md) before the next push.

import time
import traceback
import warnings
from collections import deque

_flow_control_updated is a single connection-wide asyncio.Event, but the wait condition (stream.outbound_window <= 0 or self.session_outbound_window <= 0) is per-stream.

Consequences under real multiplexing — which is the entire point of the feature:

• A WINDOW_UPDATE for stream 5 sets the shared event, waking every writer on streams 1, 3, 7… Each re-checks its own still-empty window, clears the event, and sleeps again — a thundering herd proportional to concurrent uploads.
• Worse, a writer that clears the event immediately after another writer set it can swallow the wakeup for a third writer whose window did just open, stalling it until the next unrelated update arrives.
• Line 467 (if self.session_outbound_window and stream.outbound_window: self._flow_control_updated.set()) sets the event based on one stream's state, compounding the same confusion.

Suggest a per-stream asyncio.Event (or future) for stream-window capacity plus one connection-level event for the session window, and waking only the streams whose window actually changed in _handle_window_update_frame.

            while stream.outbound_window <= 0 or self.session_outbound_window <= 0:
                self._flow_control_updated.clear()
                await self._flow_control_updated.wait()

Thanks for commenting out the module-level logger.setLevel(logging.DEBUG) — that was the bigger problem and it's resolved.

The remaining cost is that _send_frame runs on every outbound frame and builds its message with an f-string, which Python evaluates before logger.debug decides whether the level is enabled. On a multiplexed connection with large uploads that is a formatted string (plus two format() alignment specs) per DATA frame, paid unconditionally.

data_received (line 138) already uses the lazy %s form correctly — worth applying the same treatment here and in connection_lost (logger.debug(f"Connection lost: {exc}")) and _handle_settings_frame (logger.info(f"Server SETTINGS: ...")).

Also consider dropping _send_frame's debug line to a logger.isEnabledFor(logging.DEBUG) guard, since it is genuinely per-frame.

        logger.debug(
            f"-> FRAME type={frame_type.name:>15} flags=0x{flags:02x} "
            f"stream_id={stream_id:<5} length={len(payload)}"
        )

hpack >= 4.2.0 is added to dependencies, so every aiohttp install — including the overwhelming majority that will never set AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS — grows a new transitive dependency for code that is dead for them.

For a library with aiohttp's install base, adding a hard dependency for an experimental opt-in is a meaningful maintenance and supply-chain cost, and it is the kind of thing worth an explicit maintainer decision rather than a line in a feature PR.

Options, roughly in order of preference:

• Ship it as an extra (aiohttp[http2]) and import hpack lazily inside http2/, raising a clear RuntimeError if the flag is set without the extra installed.
• Import aiohttp.http2 lazily from http_protocol.py so a missing hpack is only fatal when h2 is actually negotiated. Note connector.py currently imports http_protocol at module scope, which imports http2.connection, which imports hpack — so today a missing hpack breaks import aiohttp entirely.

Minor: the entry is appended after yarl rather than inserted alphabetically (and without a trailing comma), unlike requirements/runtime-deps.in where it is correctly placed.

  "hpack >= 4.2.0"

AGENTS.md requires both for a change of this size, and neither is in the diff:

• Changelog. CHANGES/5999.feature.rst (the referenced issue) plus a symlink from the PR number, signed -- by :user:`Moist-Cat`. The chronographer check will stay red without it.
• Docs. "User-visible API changes need a docs update under docs/." A new opt-in protocol, a new response type, a new environment variable, and a new runtime dependency are all user-visible. At minimum a narrative page covering: how to enable it, that the flag must be set before import aiohttp (see the import-time finding), which ClientResponse features do and do not work, and the unsupported list from the PR description (proxies, chunking, CONTINUATION, h2c).
• THREAT_MODEL.md. AGENTS.md asks for a revision when "a public API surface is added" and when parser configuration changes. A whole new wire parser reachable from the network qualifies — the frame-size and padding findings above are exactly the kind of thing that section exists to capture.

Noting this is a draft, so this is a pre-merge checklist item rather than something to fix right now.

The coverage breadth here is genuinely good — frame-level compliance, state-machine transitions, and end-to-end ClientSession tests through a fake transport is more than most protocol PRs ship. A few things that reduce what it actually proves:

• event_loop fixture is dead code. requirements/dev.txt pins pytest-asyncio==1.4.0, where the event_loop fixture was removed; redefining it no longer changes anything. Every test instead calls asyncio.get_running_loop() directly (which is correct). Delete the fixture.
• @pytest.mark.asyncio is redundant — setup.cfg sets asyncio_mode = auto. Not wrong, just noise on ~50 tests.
• url_mock() hides two real bugs. It sets query: None and has no raw_query_string, so the query-string branch in send_request is never executed; and it has no port and no raw_host, so the :authority bug flagged above is invisible. Using a real yarl.URL here would exercise both.
• test_compressed_body_delivery's docstring says "delivers raw compressed bytes" but the assertion is resp.body == b"uncompressed", i.e. the opposite. Worth fixing so the intent is readable.
• Uncovered paths that the findings above point at: unknown SETTINGS identifier (0x7), oversized pad_length, GOAWAY with non-UTF-8 debug data, truncated RST_STREAM/WINDOW_UPDATE payloads, and a frame declaring a length above MAX_FRAME_SIZE. Each is a two-line test against the existing connection fixture.

Also: tests/http2/ has no __init__.py; worth checking that matches how the rest of tests/ is laid out for the collector.

@pytest.fixture(scope="session")
def event_loop() -> Generator[asyncio.AbstractEventLoop, None, None]:

_start_tls_connection and UnixConnector._create_connection are annotated to return ResponseHandler, but now return HttpDispatcherProtocol, so both got # type: ignore[return-value].

The author's own # HACK use the correct type comment says it: mypy is flagging a genuine model mismatch, not a false positive. Silencing it means the type system stops protecting the connector's contract — anything that later assumes ResponseHandler-specific members on these return values will fail at runtime rather than at check time.

If the dispatcher is unwrapped once ALPN is known (see the __getattribute__ finding), these signatures stay honest and both ignores disappear. Otherwise, introduce a ClientProtocol protocol/union type covering both handlers and widen the annotations to it.

Unrelated to either: the blank-line deletion at _create_direct_connection (before return transp, proto) is stray whitespace churn — worth reverting to keep the diff focused.

        # HACK use the correct type
        return tls_transport, tls_proto  # type: ignore[return-value]

4 pre-existing finding(s) on unchanged code suppressed (freeze).

Risk: HPACK uses a connection-wide dynamic table, so a failed decode desynchronises the decoder for every subsequent stream, yet this catch-all logs, resets one stream and lets the connection keep running — later responses silently decode into wrong headers instead of failing.

try:
    headers = self.hpack_decoder.decode(payload)
except Exception as exc:  # too general?
    logger.error(f"HPACK decode error: {exc}")
    self._send_rst_stream(stream_id, 1)  # PROTOCOL_ERROR
    return

Fix: Treat a decode failure as a connection error: send GOAWAY(COMPRESSION_ERROR), fail all outstanding stream futures, and close the transport rather than returning.

Risk: Dropping CONTINUATION frames silently discards the remainder of a header block that any server may split at will, and because the discarded fragment is never fed to the HPACK decoder the decoder state diverges permanently, corrupting all later responses with only a WARNING emitted.

elif frame_type in {
    FrameType.PRIORITY,
    FrameType.PUSH_PROMISE,
    FrameType.CONTINUATION,
}:
    logger.warning("%d frame ignored (not implemented)", frame_type)

Fix: Either implement CONTINUATION reassembly or fail loudly (GOAWAY + exception on the affected stream futures) when one is received; PRIORITY is safe to ignore, CONTINUATION is not.

Risk: The pending-stream loop omits the done() guard used just above, so one already-cancelled/resolved future raises InvalidStateError inside connection_lost — asyncio swallows that into the loop exception handler and every remaining waiter in _pending_streams hangs forever with no connection left to serve it.

for stream in list(self.streams.values()):
    if not stream.response_future.done():
        stream.response_future.set_exception(ConnectionError("Connection lost"))
for fut in self._pending_streams:
    fut.set_exception(ConnectionError("Connection lost"))
self.streams.clear()

Fix: Guard with if not fut.done() (and clear _pending_streams afterwards) so every waiter is failed even if one future is already resolved.

Risk: When pad_length >= len(payload) (a protocol error the comment acknowledges but does not handle) the slice silently yields empty or wrongly-truncated bytes, so the caller receives a corrupted response body with no error at all.

if flags & FlagData.PADDED:
    pad_length = payload[0]
    pos = 1

# padding might be too long
data = payload[pos : len(payload) - pad_length]

Fix: Validate pad_length < len(payload) - 1 and raise a connection-level PROTOCOL_ERROR (GOAWAY) instead of slicing blindly.

Risk: The range check does not match the enum (0x0 and 0x7 are unassigned but pass <= 9), so Setting(identifier) raises ValueError for settings the RFC requires clients to ignore; the exception escapes data_received into asyncio's fatal-error path, killing the connection with an unrelated ConnectionError and never sending the SETTINGS ACK.

if identifier < 0 or identifier > 9:
    logger.warning("Unknown setting identifier %d", identifier)
    continue
setting = Setting(identifier)

Fix: Replace the numeric range test with membership (try: setting = Setting(identifier) / except ValueError: continue) so unknown settings are genuinely ignored.

Risk: GOAWAY debug data is arbitrary bytes, so extra.decode() (evaluated eagerly, before the cancellation loop) can raise UnicodeDecodeError — and a short payload makes struct.unpack raise — aborting the handler before any stream is failed, so the real shutdown reason is replaced by an opaque transport error.

last_stream_id, error_code = struct.unpack("!I I", payload[:8])
...
logger.info(
    "GOAWAY received: last_stream=%d, error=%d, extra=%s",
    last_stream_id, error_code, extra.decode(),
)
# Cancel streams with higher IDs

Fix: Validate the payload length, use extra.decode(errors='replace') (or %r on the raw bytes), and perform the stream cancellation before any logging.

Risk: _release(should_close=False) appends the protocol to _conns[key], so releasing the same protocol twice per request leaves duplicate free-pool entries that grow unboundedly and hand the "same" connection to concurrent callers, while on the failure path conn.close() closes a protocol still sitting in that pool so later requests silently pick up a dead connection.

connector._release(conn._key, conn._protocol, should_close=False)
connector._acquired.add(conn._protocol)
...
connector._release(conn._key, conn._protocol, should_close=False)
conn._protocol = None

Fix: Track the h2 protocol explicitly (a dedicated per-host h2 registry) instead of round-tripping it through _release/_acquired, and ensure the error path removes it from _conns before closing.

Risk: Bytes for an unknown/closed stream are dropped before session_inbound_window is decremented and before any connection-level WINDOW_UPDATE is emitted, so the client's and server's views of the session window silently diverge until the server stops sending and every request stalls.

stream = self.streams.get(stream_id)
if stream is None:
    if stream_id > self._last_peer_stream_id:
        self._send_rst_stream(stream_id, 1)  # PROTOCOL_ERROR
    return

Fix: Account for len(payload) against the session window (and emit the WINDOW_UPDATE) before returning early.

Risk: RST_STREAM and WINDOW_UPDATE payloads are unpacked without a length check, so a frame of any size other than 4 bytes raises struct.error out of data_received, which asyncio converts into a generic fatal transport error that hides the actual protocol violation from both logs and callers.

error_code = struct.unpack("!I", payload)[0]
...
increment = struct.unpack("!I", payload)[0]

Fix: Check len(payload) == 4 and emit an explicit FRAME_SIZE_ERROR (GOAWAY / RST_STREAM) instead of letting struct.error escape; also mask the reserved high bit of the WINDOW_UPDATE increment.

Risk: A response missing the mandatory :status pseudo-header (a protocol violation) is silently reported to the caller as a legitimate HTTP 500 from the origin, making a client-side parsing bug indistinguishable from a real server error; a non-numeric value additionally raises a bare ValueError.

# no status error implies a server side error
self.status: int = int(self.headers.get(":status", 500))

Fix: Raise a protocol error when :status is absent or non-numeric rather than fabricating 500.

Risk: Encodings aiohttp otherwise supports (br, zstd) fall through this check, so the still-compressed bytes are handed back as .body/.text()/.json() and surface later as a confusing decode/JSON error far from the cause.

encoding = self.headers.get("content-encoding", None)
if encoding in {"gzip", "deflate"}:
    comp = ZLibDecompressor(encoding=encoding)
    body = comp.decompress_sync(body)

Fix: Handle the remaining supported encodings (or raise ContentEncodingError for an unrecognised content-encoding) instead of returning the raw payload.

Risk: self.connection is initialised to None and never assigned anywhere, so Http2Response.close() — including the call _connect_and_send_request makes on its error path — is unconditionally a no-op and the underlying stream/connection is never torn down.

def close(self) -> None:
    if self.connection:
        self.connection.close()

Fix: Wire the owning stream/protocol into the response and reset the stream (RST_STREAM) on close(), or make the method raise NotImplementedError until it is implemented.

Risk: os.getenv returns a string, so AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS=0 / =false silently enables the experimental HTTP/2 path, and the default False (rather than None) hides that this is a string comparison at all.

protocols = ["http/1.1"]
if os.getenv("AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS", False):
    protocols += ["h2"]

Fix: Parse the value explicitly, e.g. os.environ.get("AIOHTTP_ENABLE_EXPERIMENTAL_PROTOCOLS", "").lower() in {"1", "true", "yes"}.